High-availability clusters (also known as HA clusters or failover clusters) are groups of computers (nodes) that support running server applications with a minimum of down-time. A high-availability cluster uses groups of redundant computing resources in order to provide continued service when individual system components fail. More specifically, high-availability clusters eliminate single points of failure by providing multiple servers, multiple network connections, redundant data storage, etc. Absent clustering, if a server running a particular application fails, the application would be unavailable until the server is restored. In high-availability clustering, the failure of a server (or of a specific computing resource used thereby such as a network adapter, storage device, etc.) is detected. Steps are automatically taken to allow the application that was being run on the failed server to remain available. This can be in the form of restarting the server and application, using a different network resource (e.g., network adapter), or automatically restarting the application on another computing system (i.e., another node of the cluster). This process is called “failover.” High-availability clusters are often used for critical server applications such as enterprise databases, important business applications, electronic commerce websites, etc. Even a short period of downtime for such applications can be extremely expensive, especially in certain industries such as banking and telecommunications.
In computer storage, logical volume management is a flexible method of allocating space on mass-storage devices. In particular, a volume manager can concatenate, stripe together or otherwise combine underlying physical partitions into larger, virtual ones. An administrator can then re-size or move logical volumes, potentially without interrupting system use. A cluster volume manager extends volume logical management across the multiple nodes of a cluster, such that each node recognizes the same logical volume layout, and the same state of all volume resources of all nodes. Under cluster volume management, any changes made to disk or volume configuration from any node in the cluster are recognized by all the nodes of the cluster. In order to support cluster level volume management, the cluster is reconfigured when new nodes join the cluster, and when existing nodes leave the cluster.
A cluster uses interconnections (links) between the nodes for data and administrative communication. Corrective actions need to be taken if a link fails. The efficiency and timeliness of recovering from failovers and other cluster activity depends on the speed with which the cluster is able to detect and process the link failure. An individual node can use operating system services to detect whether any of its links have failed. Where two nodes are connected directly (using crossover cable) without any switches, the link-down notification is received by both of the nodes such that they can react to this event in parallel. However, where more than two nodes are coupled using switches, only the local node learns of the link failure in real time. Thus, because of the network topologies in a cluster, typically only a single node or a localized subset of nodes learns of a link failure immediately. Conventionally, the other nodes subsequently learn of the connection failure through a cluster wide heartbeat mechanism used to monitor the status of each node in the cluster. The heartbeat mechanism is relatively slow compared to the time it takes an individual node to learn of a local link failure. The proper management of a cluster can depend on each node of the cluster being aware of the link failure before taking corrective action. The interval of time until each node learns of the failure through the heartbeat mechanism delays any cluster reconfiguration or failover activity necessitated by the downed connection, and causes additional problems with the management of the cluster, such as with the execution of fencing arbitration decisions. Furthermore, incorrect or undesirable recovery activity can occur where the nodes of the cluster learn of a link failure at different times.
It would be desirable to address these issues.